<!DOCTYPE HTML>
<html>
<head>
<title>Boomerang Howto #7: Protecting the beacon from abuse</title>
<meta http-equiv="Content-type" content="text/html; charset=utf-8">
<link rel="stylesheet" type="text/css" href="../boomerang-docs.css">
</head>
<body>
<span style="float:right;"><a href="../">All Docs</a> | <a href="index.html">Index</a></span>
<h1>Boomerang Howto #7: Protecting the beacon from abuse</h1>
<p>
See <a href="../use-cases.html#uc-9">use case #9</a> for a description of this requirement.
</p>

<p>
There are two types of beacon abuse you may need to protect against:
</p>
<ol>
<li>Denial of service attacks</li>
<li>Fake beacons that do not originate from a page you own</li>
</ol>

<h2>Denial of service</h2>
<p>
There's nothing you can do in javascript to prevent denial of service attacks, but you can configure
your server to rate limit beacons originating from a single IP.  You typically shouldn't be receiving
beacons faster than a user can open websites.  You'll also want to do some operating system/web server
level configurations to detect abusive access patterns.  The majority of these are beyond the scope of
this document, but we have a few tips on building your beaconing back end to protect you from an attack.
</p>

<p>
Most developers will create a back end script that they use as the <code>beacon_url</code> parameter
of boomerang.  The problem here is that since these requests cannot be cached, this script will run
on every beacon request, and will consume web server resources, and probably database resources on
every request.  During a denial of service attack, this can bring your servers down.
</p>

<p>
A better way to handle it is to have a lightweight web server running on your beaconing server, and
have this server configured to only respond to requests for the beacon URL.  It should send back a
<code>HTTP 204</code> response to all beacon requests.  This is easy enough to configure within the
server and means that it doesn't have to do a disk lookup for any request.  The server will still
write the request to its access logs, and this should include all query string parameters and cookies.
</p>

<p>
Periodically - say once an hour or once a day (depending on the volume of beacons), you can batch process
your logs and figure out your actual beacon parameters from there, discarding any obviously fake or
abusive beacons.  The actual code to extract data from a beacon is the same regardless of whether you
do it on every request or as a batch.  See <a href="howto-0.html">Howto #0</a> for more information
on extracting data from a beacon.
</p>

<p>
There's <a href="http://learn-networking.com/network-security/how-to-prevent-denial-of-service-attacks">much</a>
<a href="http://en.wikipedia.org/wiki/Denial-of-service_attack">more</a>
<a href="http://www.cert.org/tech_tips/denial_of_service.html">information</a> online about DoS attacks
and how to protect yourself from them.
</p>

<h2>Fake beacons that do not originate from a page you own</h2>
<p>
The most common reason for this kind of abuse is that someone really liked your page design and copied
it to their own server, including the boomerang javascript, only they didn't update the beacon_url,
so it still beacons to your server.  You probably don't want this.
</p>

<p>
The easiest way to fix this is to just check the referrer of all requests and block any that don't
come from your own domain.  This works for the clueless abuser case, but not for the intentional
abuser.
</p>

<p>
The intentional abuser is someone who will try to exploit all URLs to your site just to see if they
can get something out of it.  What they try isn't really important.  There's only one legitimate way
of using your beacon, and you should block all other uses.  The best way to do this is through a
<a href="http://en.wikipedia.org/wiki/Cryptographic_nonce">nonce</a> or a
<a href="http://abhinavsingh.com/blog/2009/10/web-security-using-crumbs-to-protect-your-php-api-ajax-call-from-cross-site-request-forgery-csrfxsrf-and-other-vulnerabilities/">crumb</a>.
This is a string that is valid for one use only.  It probably includes the current timestamp and a
validity period as part of its hash.  You generate it on every page requests and add it to boomerang
using the <code>BOOMR.addVar()</code> method.  On your beacon server, you then validate the nonce
before accepting the beacon.  If you're batch processing, you'd use the timestamp of the request and
not the time that you're running the batch job in order to validate the nonce.
</p>

<pre>
BOOMR.addVar("nonce", "125a7b79de989876cce970f0768a07");	<span class="comment">// your nonce will be different</span>
</pre>

<p>
While the nonce can protect you from someone hitting your beacon URL directly, it does mean that your
main page cannot be cached, since the nonce will change on every request.
</p>

<p>
The nonce also doesn't protect you from someone pulling the beacon out of your page &mdash; with a valid
nonce, then modifying the beacon parameters and sending it off to your server.  Protecting against this
requires you to sign the parameters in the beacon, but this isn't something that you can do in javascript.
I do not know of a general purpose solution to this problem.
</p>

<p class="perma-link">
The latest code and docs is available on <a href="http://github.com/lognormal/boomerang/">github.com/lognormal/boomerang</a>
</p>

<p id="results">
</p>

<script src="../../boomerang.js" type="text/javascript"></script>
<script src="howtos.js" type="text/javascript"></script>
<script type="text/javascript">
BOOMR.init({
		user_ip: '10.0.0.1',
		BW: {
			base_url: '../../images/',
			cookie: 'HOWTO-BA'
		},
		RT: {
			cookie: 'HOWTO-RT'
		}
	});
</script>
</body>
</html>
